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Final  Report: 


DEVELOPMENT  OF  A  PROTOTYPE  SYSTEM  FOR 
SNOW  ROUTE  DESIGN  AND  MANAGEMENT 


1.  EXECUTIVE  SUMMARY 

Work  has  recently  been  completed  on  the  design  and  development  of  a  prototype  sys- 
tem for  snow  route  design  and  management.  The  results  of  this  research  fall  into  three 
separate,  but  related  areas:  1)  analysis  of  analytical  procedures  available  for  performing 
route  design  and  analysis,  2)  analysis  of  data  availability  and  adaptability  to  support 
these  analytical  procedures,  and  3)  consideration  of  the  appropriate  user  environment 
for  conducting  route  design  and  analysis  within  the  protocols  presently  recognized  by 
the  Indiana  Department  of  Highways  (IDOH).  Results  from  this  research,  which  will  be 
described  in  detail  in  this  report,  are  summarized  as  follows: 

1.  Network  optimization  methods  may  be  applied  to  problems  of  routing  service 
activities  for  those  cases  where  complete  and  accurate  data  exist  about  the 
specific  configuration  of  the  network  including  road  segment  adjacency  through 
intersections  and  segment  distances.  However,  the  result  of  this  type  of  analysis 
should  not  be  expected  to  be  an  implementable  route  design  strategy  because  the 
level  of  resolution  of  such  models  is  not  sufficient  for  representing  operational 
capability;  the  resulting  route  should  be  interpreted  as  a  good  starting  point  for 
interactive  route  design  by  an  experienced  engineer. 

2.  Improvement  in  route  specifications  may  be  expected  though  the  computational 
effort  required  for  some  network  segments  may  be  significant  and  even  prohibitive 
is  some  cases.  For  service  areas  characterized  by  rural  areas,  improvements  in 
existing  routes  in  terms  of  reduced  deadheading  may  be  expected  in  all  service 
areas.  In  some  cases,  reduction  in  numbers  of  routes  may  be  expected.  How- 
ever, for  heavily  urban  areas  such  as  the  Indianapolis  area,  an  optimization  pro- 
cedure will  likely  not  be  effective. 

3.  The  cost  effectiveness  of  the  use  of  these  models  depends  on  the  level  of  effort 
required  to  collect  and  input  required  data.  However,  satisfactory  data  already 
exist  for  use  by  these  techniques,  and  knowledge-based  techniques  for  "filtering" 
these  data  to  accommodate  the  spatial  resolution  required  for  IDOH  applications 
have  been  developed. 
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4.  In  most  cases,  route  design  is  not  an  activity  that  needs  to  be  conducted  in  real 
time,  or  even  on  a  regular  basis.  Consequently,  the  availability  of  extensive  (and 
expensive)  computer  systems  at  all  locations  where  activity  planning  is  conducted 
is  not  a  major  requirement  of  a  route  design  system. 

5.  The  needs  of  urban  areas  relative  to  route  design  and  planning  are  significantly 
different  from  rural  areas.  Special  modeling  techniques  that  are  very  different  from 
the  optimization  approach  discussed  in  previous  research  (cited  above)  are 
needed. 

The  application  of  systems  methodologies  to  problems  of  route  design  and  planning, 
therefore,  depend  on  two  considerations.  First,  can  the  systems  models,  when  properly 
applied  to  the  problem  domain,  generate  routing  solutions  that  are  by  some  measure 
superior  to  existing  routes  or  those  that  would  be  developed  without  the  aid  of  these 
models?  And  second,  can  the  data  required  to  use  these  models  be  acquired  in  a  cost 
effective  manner?  Clearly,  if  the  cost  in  time  and/or  dollars  to  collect  data  for  the  models 
are  excessive,  the  likelihood  of  their  use  is  greatly  reduced.  Both  of  these  issues  have 
been  carefully  investigated  and  further  development  is  warranted. 


2.  STATEMENT  OF  THE  PROBLEM 

The  quality  of  services  provided  by  public  institutions  is  often  very  difficult  to  quantify.  In 
contrast  to  the  private  sector,  where  engineering  management  objectives  are  usually 
specified  in  terms  of  economic  efficiency,  government  agencies  strive  to  provide  the 
"best"  level  of  service  possible  as  measured  by  public  welfare  and  safety.  These  perfor- 
mance criteria  are  generally  difficult  to  quantify  for  most  public  service  activities.  An 
important  factor,  however,  in  the  quality  of  services  provided  is  the  planning  and 
management  of  those  services.  For  an  institution  such  as  the  Indiana  Department  of 
Highways  (IDOH),  a  key  factor  in  effective  planning  and  management  is  the  ability  to 
design  efficient  route  configurations  for  the  delivery  of  services. 

The  removal  of  snow  and  ice  from  the  intrastate  highway  system  is  a  good  case  in 
point.  As  with  many  public-sector  management  operations,  snow  and  ice  control  may 
be  viewed  as  a  series  of  discrete  sub-problems:  1 )  the  locating  and  sizing  of  facilities 
for  storage  of  salt  and  abrasive  material  as  well  as  maintenance  vehicles  and  equip- 
ment; 2)  the  partitioning  of  the  physical  system  into  sub-areas  that  are  manageable  from 
the  standpoint  of  administration;  3)  the  definition  and  assignment  of  vehicle  routes;  and 
4)  the  assignment  of  available  personnel  to  snow  and  ice  control  routes.  While  other 
decompositions  are  possible  (1-4),  this  scheme  best  describes  the  problem  faced  by  the 
IDOH. 

In  developing  a  strategy  for  winter  season  snow  and  ice  removal,  the  goal  of 
(IDOH)  is  to  provide  efficient  service  within  the  constraints  on  available  resources;  plow- 
ing and  abrasive  spreading  equipment,  sand  and  salt  supplies,  and  manpower.  While 
holding  down  overall  cost  is  a  primary  consideration,  the  safety  of  the  public  is  the  major 
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objective  (5).  Public  safety  in  this  context  has  two  distinct  but  related  components:  1) 
the  condition  of  the  road  surface  (6),  and  2)  the  performance  of  the  snow  removal  fleet 
during  the  operation.  An  effective  snow  removal  operation  is  one  that  provides  rapid 
and  orderly  snow  removal  and  abrasive  application  without  excessive  interference  with 
public  transportation  activity  (5-7). 

The  routing  of  vehicles  for  snow  and  ice  control  is  the  most  difficult  of  public-sector 
routing  problem.  Yet  the  data  required  for  solving  this  problem  are  not  significantly  dif- 
ferent than  those  required  for  other  service  planning  and  management  problems.  Con- 
sequently, the  resulting  system  will  be  of  use  to  maintenance  engineers  for  a  wide  range 
of  applications  such  as  scheduling  and  routing  of  mowing,  painting,  weed  control,  facili- 
ties and  equipment  servicing,  inspection,  and  possibly  some  pavement  maintenance 
activities. 

2.1  Vehicle  Routing  and  Scheduling 

The  topic  of  vehicle  routing  and  scheduling  covers  such  activities  as  retail  distribution, 
school  bus  routing,  mail  delivery,  street  sweeping  and  snow  removal,  waste  collection, 
and  communications  system  management.  Yet  given  this  diverse  spectrum  of  applica- 
tions the  entire  field  of  study  can  be  partitioned  into  two  major  categories:  1)  routing 
vehicles  where  one  is  only  concerned  with  developing  a  set  of  routes  to  satisfy  demand 
at  several  points  or  streets,  and  2)  scheduling  vehicles  where  one  is  concerned  with 
satisfying  demand  given  time  windows  or  precedence  relations  with  regard  to  the 
demand  points.  Some  literature  chooses  to  make  the  major  partition  of  the  topic  at 
demand  type.  That  is,  does  the  demand  for  service  originate  from  points  making  it  a 
node  covering  problem  or  does  it  exist  along  the  length  of  the  street  making  it  an  arc 
covering  problem. 

The  paper  by  Bodin  and  Golden  (9)  provides  an  excellent  taxonomy  for  vehicle 
routing  and  scheduling.  It  demonstrates  the  wide  range  of  problem  characteristics  that 
can  exist  when  a  real  world  problem  is  modeled  for  solution  in  the  abstract.  This  paper 
then  goes  on  to  provide  a  general  classification  of  solution  strategies  for  the  general 
vehicle  routing  problem  and  several  examples  of  scheduling  problems  and  how  they  are 
solved.  Alternately,  the  paper  by  Golden  (10)  contains  a  rather  thorough  coverage  of 
the  traveling  salesman  problem  and  general  vehicle  routing,  but  is  lacking  in  its  cover- 
age of  the  Chinese  postman  problem  or  arc  covering  applications.  Golden  has  broken 
the  area  of  routing  into  three  principle  network  theories,  the  traveling  salesman  problem, 
the  vehicle  routing  problem,  and  the  Chinese  postman  problem.  He  describes  very  well 
the  topic  of  the  traveling  salesman  problem  from  both  perspectives,  exact  solution  pro- 
cedures and  heuristics. 

2.2  Special  Considerations  for  Snow  and  Ice  Control 

Snow  and  ice  control  during  the  winter  months  in  Indiana  is  a  major  operation  (8).  The 
Department  must  routinely  maintain  some  1 1 ,414  miles  of  roadway  throughout  the  state. 
Because  each  traffic  lane  must  receive  service,  this  translates  into  more  than  29,000 
miles  overall.   The  resources  needed  for  this  operation  include  nearly  1 ,500  trained 
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personnel  and  some  1,088  maintenance  vehicles.  The  cost  is  enormous;  over  $12- 
million  was  budgeted  by  the  State  of  Indiana  to  support  the  operation  during  the 
1 985-86  winter  season. 

The  management  of  the  operation  is  extremely  complex  due  to  several  factors.  In 
addition  to  the  magnitude  of  the  overall  operation,  uncertainties  as  to  the  duration  and 
severity  of  the  snow  emergency  pose  special  problems.  State  roads  are  categorized 
into  three  classifications  based  on  historical  average  daily  traffic  (ADT).  Class  I  roads 
(major  traffic  arteries  including  interstates  and  their  associated  ramps  and  roads  with 
ADT  greater  than  5000)  receive  continuous  service  including  plowing  and  the  application 
of  chemicals  and  abrasives  as  needed  to  keep  the  road  surface  wet  and  bare.  Class  II 
roads  (routes  having  ADT  between  1000  and  5000)  receive  continuous  plowing  and 
sufficient  chemicals  and  abrasives  to  maintain  a  bare  wet  pavement  in  the  center  portion 
of  the  roadway.  Class  III  roads  (ADT  less  than  1000)  receive  enough  service  to  keep 
the  routes  passable,  with  chemical  treatment  only  for  hills,  curves  and  intersections. 
However,  due  to  uncertainties  associated  with  snow  episodes,  these  criteria  serve  only 
as  general  guidelines;  actual  service  levels  are  often  determined  as  the  operation 
progresses. 

Following  a  snow  episode,  extensive  "clean-up"  activities  must  be  instituted  con- 
sisting of  additional  plowing  and  spot  application  of  chemicals  to  remove  all  remaining 
snow  from  driving  surfaces.  This  also  includes  clearing  of  shoulder  areas  and  special 
servicing  of  drains,  overpasses  and  bridges,  drifts,  and  the  maintenance  equipment 
itself.  Timing  is  extremely  important  in  all  phases  of  the  operation. 

Snow  and  ice  control  is  administered  at  the  sub-district  and  site  level  consistent 
with  pre-established  "snow  routes"  of  which  there  are  some  986  at  present.  Routes 
proper  may  not  begin  at  a  site  location.  In  cases  where  a  truck  must  travel  to  the  start- 
ing point  of  a  route,  no  service  will  be  conducted  during  this  time.  Such  travel  is  referred 
to  as  "deadhead"  travel.  Deadhead  miles  account  for  nearly  9,000  vehicle  miles  per 
season.  Though  travel  times  will  fluctuate  with  overall  conditions,  design  operation  calls 
for  plowing  intensities  dependent  on  roadway  classification.  In  general,  a  route  may  be 
completely  serviced  in  2  -2.5  hrs. 

Finally,  the  operation  is  complicated  by  the  presence  of  public  traffic.  Plowing  and 
spreading  is  most  effective  within  a  range  of  speed  for  the  maintenance  vehicle.  When 
vehicle  movement  is  restricted,  performance  decreases  and  road  conditions  will  further 
deteriorate  causing  additional  problems  and  potentially  dangerous  conditions. 

In  designing  an  overall  management  strategy  for  snow  and  ice  control,  a  number 
of  difficult  questions  may  be  posed:  What  is  the  best  set  of  routes  for  maintenance  vehi- 
cles so  as  to  minimize  overall  deadhead  miles  (minimize  excess  cost)?  What  charac- 
teristics of  individual  routes  are  most  important  in  terms  of  overall  safety  of  operation? 
How  best  should  vehicles  be  re-stocked  with  sand  and  chemicals  during  the  operation? 
What  contingencies  should  be  provided  to  compensate  for  the  uncertainties  of  storm 
intensity?  What  is  the  best  allocation  of  vehicles  to  sites  and  routes  to  vehicles?  Are  the 
current  administrative  boundaries  optimal  or  should  the  configuration  of  sub-districts  be 
modified?  Where  should  new  facilities  be  constructed  to  best  enhance  overall  system 
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performance?  These  questions  and  more  should  be  considered  in  the  design  of  an 
effective  strategy  for  conducting  winter  road  maintenance. 


3.  MODEL  STRUCTURE  AND  EXPECTED  RESULTS 

3.1  Prototype  Model  Structure  and  Function 

The  focus  of  this  section  is  the  description  of  the  evolution  of  an  arc  covering  algorithm 
for  the  design  of  snow  removal  routes.  One  of  the  first  considerations  in  the  design  of 
any  algorithm  is  the  data  format  and  structure.  For  the  snow  control  problem,  the  pri- 
mary source  of  data  is  the  network  of  state  and  county  roads  that  may  be  modeled  as  a 
large  link-node  diagram.  Each  road  is  represented  as  a  directed  link  with  attributes  such 
as  length,  class  or  priority,  and  the  start  and  end  nodes.  The  nodes  represent  the  inter- 
section of  two  or  more  roads,  a  depot,  or  a  point  where  a  vehicle  may  turn  around.  The 
next  section  of  this  report  provides  a  more  detailed  description  of  the  data  considera- 
tions with  regard  to  the  readily  available  digital  roadway  data  from  the  USGS. 
Throughout  this  research,  all  algorithm  and  model  development  has  been  done  with  the 
benefits  and  current  limitations  of  the  aforementioned  source  of  digital  data  in  mind. 
The  design  of  a  system  for  establishing  a  database  of  this  type  using  existing  digital 
maps  is  the  focus  of  the  following  Chapter.  With  a  viable  source  and  structure  for  the 
data,  we  may  now  consider  an  exact  algorithmic  approach  to  the  problem  of  designing 
snow  routes. 

In  the  world  of  network  algorithms  the  problem  of  snow  removal  is  an  arc  covering 
application  in  that  we  are  concerned  with  covering  every,  or  a  subset  of  every,  link  or 
road  in  the  network.  The  basic  mathematical  programming  formulation  for  this  applica- 
tion is  known  as  the  Chinese  Postman  Problem  (CPP).  The  objective  of  the  CPP  is  to 
find  the  least  cost  path  through  the  network  which  covers  every  arc  at  least  once  and 
starts  and  ends  at  the  same  node.  For  the  snow  removal  problem  least  cost  is  minimum 
distance  and  arcs  that  are  traversed  more  than  once  are  tallied  up  as  deadhead  miles; 
for  our  purposes  the  CPP  models  one  tuck  with  infinite  capacity  starting  from  and  return- 
ing to  a  common  depot  with  the  of  objective  covering  every  road  in  the  network  while 
minimizing  total  deadhead  miles.  Though  this  is  not  a  realistic  representation  of  the 
actual  multiple  truck  and  depot  problem,  it  does  provide  a  lower  bound  on  how  well  we 
can  hope  to  do  and  a  good  starting  point  for  more  complex  models.  Our  CPP  mathemat- 
ical program  is  a  minimum  cost  flow  based  formulation  and  is  shown  below: 
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In  this  formulation  x-,j  represents  how  many  times  the  arc  (i,j)  is  covered  in  the 
optimal  solution.  The  objective  (Equation  1)  is  to  minimize  the  total  distance  traveled, 
which  is  the  summation  of  how  many  times  an  arc  is  covered,  Xg,  times  the  length  of  the 
arc,  djj.  The  first  constraint  set  (Equation  2)  enforces  flow  continuity  for  all  n  nodes  in 
the  networks;  every  time  a  truck  enters  a  node  it  must  also  leave  that  node.  The  final 
constraint  set  (Equation  3)  states  that  every  arc  must  be  covered  at  least  once  and  that 
the  answers  must  be  integer.  It  makes  no  sense  to  say  that  the  truck  must  cover  any 
given  arc  a  fractional  number  of  times.  Finally,  though  this  is  an  integer  or  discrete  for- 
mulation, it  will  result  in  integer  solutions  when  solved  as  a  continuous  linear  program 
because  of  the  unimodular  constraint  matrix. 

The  first  step  toward  model  realism  is  to  realize  that  IDOH  is  only  responsible  for  a 
subset  of  all  the  roads  in  the  state.  That  is,  IDOH  only  has  to  service  state  roads,  high- 
ways, and  interstates,  but  their  trucks  may  very  well  need  to  traverse  a  county  road  to 
provide  service  to  a  state  road.  Therefore  city  streets  and  county  roads  should  be 
included  in  the  data,  but  with  a  flag  designating  them  as  merely  non-required  arcs  that 
may  be  used  to  provide  more  efficient  service  or  reduce  deadheading  miles.  With  the 
data  so  marked  a  variant  of  the  CPP  known  as  the  Rural  Postman  Problem,  R-CPP,  can 
be  used  to  solve  the  problem.  The  formulation  is  identical  to  the  CPP  except  for  the 
addition  of  one  constraint  and  is  shown  below: 


n     n 

Minimize      SSdyXy  (1) 

n  n 

Subjectto:     Xxki-Xxik  =  rj  foralli  (2) 

k=1  k=1 

X|j>1  &  integer  forall  (i,j)e  R  (3) 

X|j>0&  integer  forall  (i.j)e(A-R)  (4) 


This  formulation  employs  the  notion  of  the  set  R  which  denotes  the  set  of  all  arcs  that 
IDOH  is  required  to  service  and  the  set  A  which  is  the  set  of  all  of  the  arcs  in  the  net- 
work. Therefore  the  additional  constraint  set  (Equation  4)  states  that  all  arcs  that  are 
not  required  to  be  serviced  by  IDOH  do  not  have  to  be  covered,  but  may  be  traversed. 
This  discrete  model  will  solve  integer  when  run  as  a  linear  program,  but  a  major  problem 
can  develop.  Consider  the  simple  six  node  example  of  the  network  below  (Figure  1  A) 
and  its  corresponding  solution  when  a  R-CPP  is  run  (Figure  1B).  Note:  arc  lengths  are 
irrelevant  and  arcs  (3,4),  (4,3),  (2,6),  and  (6,2)  are  not  required. 

This  example  demonstrates  the  very  common  and  frustrating  occurrence  of  sub- 
tour  generation.  The  solution  in  Figure  1B  is  optimal,  but  represents  an  impossible  route 
for  a  truck  to  traverse  because  of  the  existence  of  two  subtours:  (1->2->1->6->1)  and 
(3->4->5->4->3).  There  is  no  way  to  trace  a  path  from  node  one  which  covers  all  of  the 
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FIGURE  1  -  Arc-Node  Configuration  for  Optimization  Model 
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required  arcs  and  returns  to  node  one. 

Subtour  generation  is  the  major  stumbling  block  in  the  formulation  of  any  type  of 
exact  routing  algorithm.  There  is  a  large  body  of  literature  that  addresses  this  problem 
from  many  different  angles,  but  for  our  current  purpose,  an  exact  solution  for  the  R- 
CPP,  it  is  sufficient  to  discuss  only  one.  The  subtours  could  be  eliminated  if  there 
existed  constraints  in  the  R-CPP  formulation  that  would  not  allow  them  to  be  formed  in 
the  first  place.  The  problem  with  these  constraints  is  that  there  are  an  exponential 
number  of  possible  subtours  that  can  be  formed,  based  on  the  number  of  nodes,  there- 
fore there  are  an  exponential  number  of  possible  constraints  that  could  be  added  to  the 
model  to  stop  their  formation.  Two  problems  exist  with  these  additional  constraints:  one, 
for  problems  of  any  realistic  size,  say  100  plus  nodes,  the  number  of  subtour  breaking 
constraints  grows  to  an  outlandish  size  and  two,  these  constraints  force  the  model  off  of 
integer  linear  programming  solutions.  With  the  loss  of  integer  linear  programming  solu- 
tions we  are  forced  to  employ  an  integer  programming  code  such  as  branch  and  bound 
which  could  enumerate  for  eternity  with  a  problem  of  100  plus  integer  variables  and  an 
exponential  number  of  constraints  and  never  find  an  optimal  solution.  But  before  giving 
up  entirely  on  the  CPP  based  exact  approach,  let  us  evolve  the  model  one  step  further 
by  imposing  the  fact  that  multiple  trucks  will  be  used  to  service  the  network. 

The  previous  model,  R-CPP,  used  the  idealized  one  truck  of  infinite  capacity. 
Indiana's  current  snow  control  operations  utilize  multiple  trucks  emanating  and  returning 
to  a  common  depot  of  which  there  are  several  grouped  into  subdistricts  that  in  turn  are 
part  of  larger  districts.  If  we  restrict  our  resolution  to  one  depot  in  any  given  subdistrict, 
the  R-CPP  may  be  extended  to  accommodate  multiple  vehicles  and  result  in  a  formula- 
tion we  will  call  the  M-Rural  Postman  Problem,  MR-CPP.  This  mathematical  program  is 
a  bit  more  complex  and  is  shown  below: 


Minimize      Z  Z  Z  du  xf[" 

W  j=1  k=1 


n  n 


Subjectto:     £  xfl- £  x8?  =  0  foralli.m 

k=1  k=1 


EEdijX^MAXMILES  for  all  m 

m 

2  xjj"  2s  1&  integer  forall(i,j)eR 

k=1 


£x^>0&  integer  forall(i,j)e(A-R) 

k=1 


xdepot  -  1 


for  all  m 


(5) 

(6) 

(7) 

(8) 

(9) 
(10) 
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The  MR-CPP  has  a  modified  decision  variable,  xfj\  which  designates  which 
truck(s)  will  cover  each  arc  (i,j),  so  that  there  are  now  m*n  integer  decision  variables  in 
the  formulation.  The  objective  function  (Equation  5)  is  the  same:  minimize  total  distance 
traveled  by  all  m  trucks.  The  continuity  constraint  (Equation  6)  is  the  same  flow  con- 
tinuity set,  but  now  they  are  summed  for  every  truck  at  each  node.  Vehicle  capacity  con- 
straints (Equation  7)  enforces  vehicle  capacity  by  setting  the  constant  MAXMILES  equal 
to  the  maximum  number  of  miles  each  truck  may  travel.  The  next  two  constraint  sets 
(Equation  8)  and  (Equation  9)  are  the  same  as  before,  but  they  must  also  be  summed 
over  all  the  vehicles.  The  final  set  of  constraints  (Equation  1 0)  forces  every  vehicle  to 
emanate  from  the  common,  designated  depot. 

With  the  inclusion  of  subtour  elimination  constraints  and  the  fact  that  there  are  m*n 
integer  variables  in  this  formulation,  the  MR-CPP  becomes  even  more  of  a  hopeless 
case  as  far  as  an  exact  solution  via  mathematical  programming  is  concerned.  But  this 
formulation  does  give  one  an  idea  of  the  complexity  and  size  of  exact  routing  models  as 
more  real  world  or  problem  constraints  are  imposed  on  the  problem.  Furthermore,  an 
essential  dimension  of  the  problem  is  missing  from  the  MR-CPP,  the  fact  that  there  are 
multiple  depots  in  each  subdistrict.  We  feel  that  at  a  minimum  any  design  or  analysis  of 
routes  and  their  configurations  should  be  done  at  a  subdistrict  resolution.  A  Multi-depot 
MR-CPP  formulation  would  be  a  true  mess  and  given  the  combinatorial  explosion  we 
have  witnessed  at  the  R-CPP  and  MR-CPP  level,  a  listing  and  explanation  would  be 
useless  at  this  point. 

What  has  been  useful  in  creating  and  manipulating  these  exact  formulations  is  the 
insights  into  the  problem  complexity  they  have  unveiled.  So  far  in  our  research  we  have 
not  discovered  an  efficient  method  to  handle  the  different  road  classifications  or  priori- 
ties, given  that  each  route  should  have  class  continuity.  One  way  to  handle  this  would 
be  to  partition  the  network  into  three  sub-networks,  one  for  each  classification,  and  run  a 
routing  algorithm  on  each  one.  This  procedure  assumes  that  route  continuity  is  an  abso- 
lutely binding  constraint,  which  it  is  not  because  the  current  set  of  IDOH  routes  violate 
route  continuity.  Therefore  this  topic  is  better  classified  as  a  minor  objective,  that  could 
possibly  be  handled  with  a  penalty  function.  This  leads  to  the  point  of  identifying  the  true 
objective  of  this  problem. 

The  public  sector  problem  of  snow  and  ice  control  is  in  reality  a  multi-objective 
problem.  While  minimizing  cost,  total  distance  and  number  of  trucks,  IDOH  also  wishes 
to  maximize  the  level  of  service  to  the  public.  This  could  be  handled  with  some  multi- 
objective  optimization  paradigm  such  as  iterative  trials  holding  level  of  service  constant 
and  minimizing  cost  or  maximizing  efficiency. 

A  final  point  on  these  exact  procedures  is  that  while  they  are  computationally 
impossible,  they  do  provide  the  basic  groundwork  for  formal  heuristic  methods  such  as 
linear  programming  column  generation  schemes,  Lagrangian  relaxation  procedures,  and 
others.  These  heuristic  methods  are  appealing  because  they  are  based  on  the  exact 
models  and  are  therefore  easy  to  justify  and  build  the  routes  up  from  nothing  to  near 
optimal  in  a  logical  form. 
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The  previously  mentioned  heuristic  methods  design  routes  from  scratch,  another 
viable  heuristic  approach  is  to  randomly  create  routes  and  try  to  improve  them  or 
improve  existing  routes.  Since  IDOH  has  a  set  of  a  routes  which  have  historically 
evolved  and  were  created  by  experts,  a  heuristic  procedure  that  tries  to  improve  these 
existing  routes  is  probably  the  best  approach.  Two  such  methods  are  a 
swap/improvement  heuristic  and  a  route  elimination  heuristic. 

The  swap  heuristic  answers  the  basic  question:  Can  the  current  routes  be 
improved?  Indicators  of  improvement  could  be  less  total  deadheading,  better  enforce- 
ment of  route  continuity,  greater  route  compactness,  and  other  factors  that  only  experi- 
enced IDOH  personnel  can  provide.  A  heuristic  algorithm  of  this  type  requires  the  net- 
work data  previously  mentioned  and  the  current  routes  to  be  digitally  encoded  in  a  simi- 
lar format.  It  then  tries  to  modify  the  routes  based  on  the  objectives  listed  above  by 
swapping  arcs  between  routes  or  cutting  down  on  deadheading.  This  method  results  in 
more  efficient  and  hopefully  easier  to  drive  routes  which  in  turn  results  in  a  better  level 
of  service. 

The  elimination  heuristic  answers  the  question:  Do  we  need  all  the  routes  that  are 
currently  used  to  service  the  network?  This  method  requires  the  same  digitally  encoded 
data  as  the  improvement  method.  It  ranks  and  sorts  the  current  routes  based  on  total 
and  deadheading  length,  total  number  of  arcs  it  covers,  and  nodes  it  shares  with  a  route 
of  the  same  classification.  The  algorithm  would  then  try  to  eliminate  a  route  by  breaking 
it  up  and  distributing  its  arcs  among  other  routes.  This  method  results  in  fewer  needed 
trucke  that  are  one  of  the  major  costs  involved  in  snow  and  ice  control. 

3.2  Preliminary  Analysis:  The  Fowler  Subdistrict 

The  methods  discussed  in  the  previous  section  have  been  investigated  using  data  from 
the  Fowler  Subdistrict,  the  project's  test  site.  At  this  point  in  the  evolution  of  this  project 
the  aforementioned  USGS  digital  data  is  still  not  fully  compatible  with  the  routing  work  of 
this  section,  yet  it  is  inherently  important  to  any  successful  design  or  analysis  previously 
outlined.  To  overcome  this  preliminary  incompatibility  we  have  quite  crudely  created  our 
own  digital  data  with  maps  and  a  ruler.  This  effort  has  resulted  in  a  362  arc,  99  node 
link-node  diagram  that  was  hand  encoded  from  a  terminal.  Therefore  at  this  point  it 
should  be  stressed  that  there  is  no  real  indicator  of  the  accuracy  of  this  source  of  data. 
One  limitation  of  the  data  is  that  only  those  roads  currently  used  by  IDOH  in  snow  ser- 
vicing were  considered. 

A  Chinese  Postman  Problem  formulation  was  created  and  run  based  on  the  test 
data.  It  resulted  in  a  linear  program  with  362  variables,  99  flow  continuity  constraints, 
and  an  optimal  solution  of  905.9  lane  miles  required  to  service  the  network  (see  Appen- 
dix A  for  model  listing).  Only  2.39  miles  were  deadheading.  Figure  2  represents  the  flow 
of  information  from  raw  digital  data  to  the  output  of  a  mathematical  model. 

The  digital  data  are  currently  the  hand  encoded  network.  In  the  future,  digital  data 
will  be  used  as  described  in  the  following  chapter.  Network  data  structures  are  two 
inter-linked  linked  lists  of  the  nodes  and  arcs  and  their  respective  attributes  that  are 
created  by  a  program  that  reads  the  raw  digital  data  and  generates  the  lists  of 
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FIGURE  2  -  Schematic  Representation  of  Optimization  Model 


structures.  These  linked  lists  of  structures  can  be  used  to  generate  a  XML  model, 
mathematical  program,  or  feed  a  heuristic  algorithm.  Finally  XMP  is  the  mathematical 
programming  software  which  solves  the  models  and  generates  the  results. 

The  swap/improvement  and  elimination  heuristics  were  evaluated  with  hand 
encoded  data  and  the  routes  as  currently  defined  by  IDOH  as  the  data  source.  In  the 
process  of  imposing  the  IDOH  route  definitions  on  the  network  definition,  many 
shortcomings  or  conflicts  were  discovered  between  the  two.  While  many  of  the  conflicts 
were  resolved  by  editing  the  hand  encoded  data,  some  still  exist  which  will  probably 
require  the  actual  visitation  of  the  points  in  question. 

The  computational  effort  and  routing  expertise  required  for  the  definition  and 
implementation  of  the  swap/improvement  heuristic  made  its  implementation  prohibitive 
in  the  current  project.  A  very  rudimentary  elimination  heuristic  was  hand  tested  with  the 
Fowler  data  and  routes.  The  result  was  the  elimination  of  one  route,  13-E-1,  from  unit 
one's  group  of  routes.  In  eliminating  this  route  three  others,  13-H-2,  13-A-1,  13-F-1, 
were  consequently  modified.  The  removal  of  route  13-E-1  resulted  in  a  loss  of  15.8 
deadhead  miles  and  a  surplus  truck.  The  three  modified  routes  all  stay  within  the 
prescriptions  set  forth  in  the  documented  policy,  but  will  need  to  be  evaluated  by  the 
appropriate  personnel  with  regard  to  a  realistic  implementation.  The  following  table 
(Table  1)  sums  up  the  various  methodologies  that  have  been  discussed  and  their 
respective  parameters. 

In  conclusion,  an  empirical  analysis  of  the  Fowler  subdistrict  was  undertaken  to 
determine  the  minimum  number  of  routes  required  to  service  the  network.  There  are 
approximately  457  lane  miles  of  class  I  roads  ,  271  lane  miles  of  class  II  roads,  and  188 
lane  miles  of  class  III  roads  and  class  I,  II,  and  III  routes  can  not  exceed  35,  50,  and  65 
miles  respectively.  With  the  previous  given  facts  the  fowler  subdistrict  should  optimally, 
no  deadheading,  need  13  class  I  routes,  6  class  II  routes,  and  3  class  III  routes  or  a  total 
of  22  routes.  The  current  IDOH  configuration  calls  for  a  total  of  26  routes  or  4  extra 
routes  above  the  minimum  needed.  Given  the  fact  that  there  must  exist  some  dead- 
heading, a  total  of  26  routes  is  not  far  from  a  feasible  optimal.  This  comes  as  no  surprise 
given  the  fact  that  each  set  of  routes  was  designed  by  a  local  "expert",  in  terms  of  local 
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Table  1 :  Methodology  Evaluation  Parameters 

Route 
Parameters 

Current 
Policy 

Theoretical  Lower 
Bound  via  CPP 

Swap  Heuristic 
Improvement 

Elimination  Heuristic 
Elimination 

Total  Required 
Lane  Miles 

915.4 

903.5 

915.4 

915.4 

Total 
Deadhead 

175.8 

2.39 

<  1 75.8 

160 

Total  Lane 
Miles  Serviced 

1091.2 

905.9 

<  1091.2 

1075.4 

#  Routes 

26 

1 

26 

25 

geography  and  snow  plow  routing. 

4.  DATA  CONSIDERATIONS 

4.1  The  Network  Reduction  Problem 

For  the  application  of  vehicle  routing  over  the  state  highway  network,  a  complete 
description  of  the  network  is  required.  This  description  must  include  all  major  intersec- 
tions in  each  district,  adjacency  information  that  indicates  which  intersections  are  joined 
directly  by  roads,  and  the  lengths  of  each  of  these  roads.  Planning  for  snow  and  ice  con- 
trol requires  additional  information  such  as  the  width  in  lanes  of  every  roadway,  and 
more  complete  descriptions  of  intersections,  including  features  such  as  turn  lanes  or 
traffic  control  devices.  Currently  the  most  effective  means  of  assembling  such  data  has 
been  to  produce  a  network  by  reading  the  information  from  a  highway  map,  and  then 
adding  additional  arcs  to  the  graph  to  account  for  multiple  lanes.  On  a  statewide  basis, 
this  process  could  prove  extremely  tedious,  with  the  accuracy  of  the  resulting  maps  less 
than  desired. 

An  objective  of  this  research  has  been  to  explore  available  digital  map  data 
sources  and  to  find  the  best  methods  to  convert  these  data  to  a  usable  network 
representation.  One  class  of  geographic  data  considered  is  a  raster,  or  grid,  format. 
Data  gathered  by  aerial  or  satellite  photography  is  in  this  form.  A  raster  format  is 
impractical  for  a  network  application  due  to  the  large  amount  of  processing  required  to 
extract  the  roadway  information  from  the  data  grid.  Also,  to  obtain  accurate  distances 
along  roads,  the  sampling  size  of  the  raster  format  must  be  fairly  small,  or  the  errors  in 
calculation  would  be  multiplied  many  times  over. 
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The  most  promising  format  for  this  application  is  a  vector  format.  Roadways  are 
represented  as  polylines,  that  is,  a  set  of  short  segments  connecting  two  intersections. 
Many  basic  functions  would  be  simplified,  especially  those  of  finding  adjacent  intersec- 
tions and  road  lengths.  The  source  for  vector  data  thus  far  has  been  the  U.S.  Geologi- 
cal Survey  Digital  Line  Graph  (DLG)  format  (11).  Roadway  information  is  available  for 
the  state  of  Indiana  at  1 :1 00000  scale. 

The  DLG  format  has  some  restrictions  that  could  hinder  the  vehicle  routing  pro- 
cess. Although  the  format  definition  allows  roads  to  be  labeled  with  the  number  of 
lanes,  no  roads  in  the  study  area  appear  to  be  coded  with  this  information.  Detail  of 
intersections  is  also  lacking  in  the  DLG  format.  For  major  interchanges  on  limited 
access  highways,  all  access  roads  and  ramps  are  included.  For  simpler  intersections, 
however,  information  on  right  or  left  turn  lanes  is  not  included.  One  solution  to  these 
problems  would  be  to  implement  an  auxiliary  database  system,  which  could  supply  addi- 
tional information,  when  necessary  in  the  routing  process.  Another  possible  solution 
would  be  to  include  some  data  from  the  higher  resolution,  1 :24000  scale  maps  which 
the  USGS  produces.  However,  these  maps  are  not  currently  available  in  digital  form  for 
the  entire  state,  and  none  is  available  for  the  roadway  layers  in  the  study  area.  Finally, 
the  USGS  data  available  are  revised  infrequently.  If  a  major  change  to  the  highway  net- 
work were  implemented,  such  as  a  new  interstate  interchange,  or  major  access  roads  to 
a  new  factory,  the  data  would  possibly  have  to  be  modified  by  IDOH  staff. 

The  largest  problem  with  using  any  digital  data  representation  of  the  highway  net- 
work is  the  sheer  amount  of  information.  For  example,  as  supplied,  the  7.5  minute  qua- 
drangle (approximately  52  square  miles)  that  includes  West  Lafayette  contains  2103 
nodes  and  3040  lines.  A  major  reason  for  the  large  amount  of  data  is  the  number  of  city 
streets  not  of  interest  to  the  IDOH  that  are  included  in  the  map.  The  same  problem 
arises  for  rural  areas,  where  county  roads  are  mapped,  but  should  not  be  part  of  the 
routing  effort.  For  the  snow  and  ice  control  problem,  a  network  consisting  only  of  major 
roads  is  necessary.  The  DLG  maps  also  contain  some  additional  information  to  define 
grid  lines  and  edges  which  can  be  removed  for  our  application.  To  address  these  con- 
cerns, a  system  has  been  developed  to  reduce  the  complexity  of  the  road  network 
represented  by  the  data  using  the  following  process: 

1 .  Remove  lines  that  do  not  represent  roads  and  identify  edge  nodes  for  later  match- 
ing. 

2.  For  adjacent  maps,  create  a  minimum  cost  edge  matching  to  produce  a  single 
map.  Repeat  until  one  map  represents  the  entire  region. 

3.  Simplify  uninteresting  intersections,  and  correct  invisible  intersections. 
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4.2  Results  of  Data  Reduction  Technique 

Figure  3  shows  the  quadrangle  that  includes  Crawfordsville  in  the  original  unfiltered 
form.  All  major  roads  are  named  within  the  file  by  attribute  codes.  All  other  roads  are 
marked  with  a  simpler  designation,  and  for  this  problem,  could  usually  be  ignored.  For 
experimental  purposes,  only  state,  U.S.,  and  Interstate  highways  are  The  first  phase  of 
the  processing  removes  these  uninteresting  roads  from  the  working  database,  included 
in  the  database.  To  perform  a  true  network  analysis  over  the  entire  district,  many  maps 
would  have  to  be  merged  into  one  map.  Therefore,  the  first  phase  also  assigns  unique 
identifiers  to  every  line  and  node,  and  identifies  edges  nodes  for  later  matching.  The 
latter  task  can  be  accomplished  by  using  equations  to  find  the  distance  between  a  point 
and  a  line.  If  this  distance  is  found  from  the  node  to  each  of  the  four  edges  of  the  map, 
the  minimum  of  these  distances  should  indicate  the  edge  on  which  the  node  lies.  After 
processing  the  data  through  this  stage,  the  map  of  Crawfordsville  in  Figure  4  is  pro- 
duced. 

The  second  phase  of  the  process  is  a  simple  algorithm  which  links  together  all  of 
the  maps  required  to  represent  a  region.  The  header  information,  which  includes  the 
corner  points  of  the  map,  is  read  in  for  both  of  the  maps,  and  the  common  edge  is 
identified.  All  lines  in  both  maps  are  saved  in  a  temporary  file.  Nodes  which  do  not  lie 
along  the  common  edge  are  also  written  to  a  temporary  file.  The  remaining  nodes  are 
held  in  two  short  lists,  with  a  one-to-one  correspondence.  Iteratively  for  each  node  in 
the  first  list,  the  distance  by  Euclidean  metric  to  every  node  in  the  second  list  is  calcu- 
lated. The  minimum  value  is  chosen  to  be  the  best  possible  match.  A  new  "match  arc"  is 
created  and  saved  in  the  temporary  file  of  lines.  The  edge  nodes  in  question  are 
modified  to  show  the  match  arc,  and  are  written  to  the  temporary  file  of  nodes.  Those 
nodes  are  also  removed  from  future  consideration  as  matches.  After  all  nodes  have 
been  matched,  the  new  map  is  assembled  from  the  temporary  files,  and  the  phase 
repeats  on  two  other  maps.  In  worst  case,  the  number  of  nodes  to  be  matched  could 
result  in  a  possibly  inaccurate  set  of  matches.  Given  the  accuracy  of  the  data,  and  the 
knowledge  that  relatively  few  of  the  roads  represented  on  the  maps  are  state  highways, 
this  process  should  still  be  considered  efficient. 

The  third  phase,  that  of  removing  uninteresting  and  incorrect  intersections,  could 
best  be  described  as  an  attempt  to  convert  the  two  dimensional  map  into  a  three  dimen- 
sional model  of  the  highway  system.  The  aim  of  reducing  the  number  of  intersections  is 
to  reduce  the  complexity  of  the  network.  Since  adjacency  information  is  vital  for  network 
analysis  problems,  a  reduction  in  number  of  nodes  results  in  a  squared  reduction  in  the 
size  of  the  adjacency  matrix.  Thus,  memory  requirements  and  processing  times  are 
likely  to  drop  by  the  same  impressive  amount. 

The  obvious  operation  of  this  phase  is  the  removal  of  unnecessary  intersections. 
As  each  node  is  considered,  the  number  of  incident  arcs  is  counted.  If  only  two  arcs  are 
incident,  it  is  likely  that  those  arcs  represent  the  same  road.  The  attribute  lists  of  the  two 
arcs  are  compared,  and  if  judged  nearly  equivalent,  the  arcs  are  merged.  After  suitable 
bookkeeping  is  performed,  one  arc  and  one  node  have  been  removed  from  the  map 
without  loss  of  information. 
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FIGURE  3  -  Original  USGS  map  of  Crawfordsville  roads 


The  second  operation,  removing  incorrect  intersections,  is  a  problem  at  locations 
with  a  road  passing  over  another.  To  maintain  planarity,  the  DLG  map  includes  an  inter- 
section at  the  crossing  of  the  two  roads.  The  road  under  the  overpass  is  marked  with  a 
special  identifying  code.  To  represent  the  highway  network  in  three  dimensions,  it  is 
necessary  to  remove  this  intersection,  while  maintaining  the  sense  of  the  overpassing 
and  underpassing.  Since  the  results  of  the  Phase  3  will  appear  virtually  identical  to  that 
of  Figure  4,  a  figure  is  not  included.  If  nodes  were  highlighted  in  these  diagrams,  an 
obvious  reduction  in  the  number  of  nodes  could  be  seen. 
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FIGURE  4  -  Crawfordsville  area  following  Phase  I  filtering 


The  overall  results  of  applying  the  process  to  the  data  of  the  study  area  is  shown 
in  the  map  of  Figure  5,  with  a  table  of  the  comparative  complexities  of  the  map  in  Table 
2.  The  final  map  is  of  a  low  enough  complexity  that  many  exact  and  heuristic  network 
analysis  algorithms  can  be  applied  efficiently  on  many  microcomputers. 

This  process  does  have  limitations  for  future  applications,  especially  in  urban 
areas.  If  city  streets  were  included  as  "interesting"  roads,  the  complexity  of  the  data 
would  not  be  reduced  by  as  large  of  a  factor.  More  importantly,  the  USGS  data  normally 
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FIGURE  5  -  Crawfordsville  area  following  final  filtering 


labels  all  minor  roads  or  city  streets  as  "road  or  street",  so  all  county  and  farm  roads 
could  be  considered  equivalent  to  city  streets.  The  most  promising  method  to  solve  this 
problem  would  involve  use  of  city  limit  information  to  identify  whether  a  road  was  in  or 
out  of  town.  Also,  the  current  process  does  not  entirely  conform  to  the  IDOH  Snow  and 
Ice  Removal  policy.  First,  travel  roads  are  not  included  in  this  network  representation. 
The  most  efficient  means  of  including  such  roads  would  be  to  allow  the  route  designer  to 
specify  where  travel  roads  would  most  likely  prove  beneficial.  The  routing  algorithm 
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Table  2  - 

Comparative  complexities  of  maps  while  being  processed 

After  Phase 

Size  in  Characters 

Number  of  Nodes 

Number  of  Lines 

As  supplied 
1 
2 
3 

6860919 
1023355 
1026154 
285302 

20055 
3294 
3294 
452 

29365 
3275 
3440 
574 

would  then  reconsider  the  routes  in  those  areas,  and  would  include  those  added  travel 
roads  if  reduced  costs  would  result.  Also,  the  USGS  classification  of  roads  does  not 
necessarily  match  those  of  the  IDOH.  Modification  of  the  data,  or  construction  of  an  aux- 
iliary database  could  provide  corrected  class  information. 

In  summary,  the  process  developed  makes  excellent  gains  in  simplifying  the  data- 
base around  which  a  routing  or  roadway  information  system  could  be  developed.  Some 
problems  do  exist  with  respect  to  conforming  to  IDOH  guidelines,  and  with  certain 
aspects  of  current  vehicle  routing.  In  general,  the  gains  made  in  data  accuracy  and 
reduction  in  data  creation  expense  should  offset  these  problems. 

5.  SUMMARY  OF  THE  SNORODES  PROTOTYPE 

The  concepts  discussed  in  the  previous  chapters  have  been  formalized  in  the  SNOw 
ROute  Design  and  Evaluation  System  (SNORODES).  The  system  exists  as  an  interac- 
tive graphics-based  prototype  using  modern  professional  workstation  technology.  This 
chapter  discusses  the  design  and  implementation  of  the  prototype  user  interface  as  well 
as  the  structure  of  the  design  and  analysis  system.  A  sample  user  session  is  provided 
as  Appendix  B  to  this  report. 

5.1  The  SNORODES  Prototype  User  Interface 

For  any  system  designed  to  represent  geographic  information,  an  accurate  representa- 
tion of  the  environment  is  essential.  To  route  snow  removal  vehicles,  the  most  important 
data  would  be  a  representation  of  the  state  highway  network.  Data  for  the  highway  sys- 
tem could  be  acquired  by  several  means  such  as: 

•  Manually  entering  locations  of  depots  and  intersections  and  distances  along  roads 
connecting  these  points 

•  Digitizing  a  state  road  map  of  the  study  area 

•  Acquiring  high-resolution  digital  maps  from  some  third-party 
Each  of  these  methods  has  peculiar  advantages  and  disadvantages. 
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Entering  the  data  by  hand  would  allow  the  designer  strong  control  over  "map 
clutter,"  as  only  the  data  for  roads  requiring  service  would  be  inserted  into  the  database. 
However,  the  accuracy  of  these  data  would  be  questionable,  as  reading  locations  from  a 
map  cannot  produce  the  exact  location  of  points.  Also,  for  even  a  small  study  area,  the 
data  volume  required  to  represent  the  network  could  be  prohibitive. 

An  automatic  method,  such  as  map  digitization,  could  reduce  the  effort  required  to 
process  a  map,  but  many  new  problems  would  arise.  No  digitization  method  is  perfect, 
so  much  effort  is  required  to  correct  the  data.  Also,  many  etements,  such  as  divided 
highways,  are  represented  by  more  than  one  line.  Use  of  image  processing  techniques 
would  be  required  to  reduce  this  representation  to  a  single  line  that  could  be  manipu- 
lated by  a  database.  Not  all  road  maps  could  be  scanned  automatically  to  produce  use- 
ful data;  the  clutter  in  most  maps  would  prevent  some  paths  from  being  plotted  correctly. 
This  error  would  result  in  incorrect  distances  between  intersections,  forcing  routing  algo- 
rithms to  produce  routes  with  incorrect  costs  for  fuel,  abrasive,  man-hours,  and  "dead- 
head" miles. 

The  method  chosen  for  this  project  is  maps  in  the  "Digital  Line  Graph"  form  from 
the  United  States  Geological  Survey  (USGS).  Produced  from  aerial  and  satellite  photo- 
graphs, these  maps  provide  high  accuracy  representations  of  roads,  railroads,  transmis- 
sion lines,  and  rivers  (see  Table  3).  As  the  maps  are  available  in  digital  form,  already 
hand  checked  for  accuracy  by  the  USGS,  no  research  time  is  spent  In  creating  the 
maps.  One  major  disadvantage  of  the  USGS  maps  is  the  tremendous  amount  of  data 
required  to  produce  a  map  of  a  small  area.  For  example,  a  sample  data  set  near  Chat- 
tanooga, Tennessee  contains  over  three  thousand  nodes,  and  over  four  thousand  line 
segments.  Not  onfy  cou/d  this  massive  size  cause  problems  for  a  database,  it  would 
greatly  increase  the  time  required  to  complete  routes  with  existing  algorithms.  Another 
drawback  of  the  USGS  data  form  is  its  infrequent  modification.  If  some  major  highways 
were  built  within  a  study  area,  the  map  data  would  have  to  be  modified  manually,  or  a 
special  request  would  be  necessary  to  update  the  original  maps  at  the  USGS.  However, 
the  accuracy  of  the  USGS  maps,  and  their  availability  in  digital  form  far  outweigh  the 
disadvantages. 

At  this  stage  in  the  design  of  the  SNORODES  system,  the  primary  focus  has  been 
on  developing  an  architecture  and  protocol  for  a  database  consisting  of  a  server  pro- 
gram that  manages  the  data,  and  various  client  programs,  such  as  the  graphic  interface. 
This  client-server  model  requires  the  host  computer  to  operate  in  a  multitasking  mode, 
that  is,  with  many  programs  sharing  the  capabilities  and  resources  of  the  processor  vir- 
tually simultaneously.  The  host  operating  system  must  also  provide  some  method  for 
interprocess  communication.  In  the  prototype  system  running  under  the  UNIX  operating 
system  on  a  SUN  workstation,  the  "socket"  mechanism  is  used.  Any  client  program  can 
open  a  connection  to  the  database  server,  and  then  request  any  number  of  data  ele- 
ments from  maps  in  the  study  area. 

A  major  limitation  of  all  operating  systems  is  the  ceiling  on  the  number  of  files  that 
can  be  accessed  at  any  time.  In  the  prototype  system,  a  swapping  method  is  used  so 
that  only  the  most  recently  used  maps  are  kept  in  active  status.  If  some  inactive  map  is 
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Table  3  -  Available  1 .100,000  USGS  Data  Elements 


Data  stored  in  USGS  DLG  Maps 


Data  Type 

Elements 

Map  Header 

name 

locations  of  comers 

scale  information 

Category  Header 

name 

number  of  nodes 
number  of  lines 
number  of  areas 

Node  Entry 

identification  number 

location 

number  of  lines  incident 

directed  lines  to  other  nodes 

number  of  attributes 

attribute  code  pairs 

Line  Entry 

identification  number 

starting  node 

ending  node 

adjacent  areas 

number  of  segments  forming  lines 

line  segments 

number  of  attributes 

attribute  code  pairs 

requested,  the  least  recently  used  map  is  returned  to  inactive  status,  and  the  newly 
requested  map  is  made  available. 

The  data  can  be  viewed  at  any  resolution,  with  a  limit  placed  when  all  of  the  avail- 
able data  is  displayed  in  the  map  display  window.  The  current  map  resolution  is  con- 
tained in  a  global  map  state  structure  so  that  the  map  can  be  redrawn  at  any  time.  Most 
functions  use  this  structure  for  reference  or  update  it  when  changes  are  made. 

A  scrolling  function  that  was  planned  for  originally  has  been  replaced  by  a  panning 
function.  This  panning  function  has  all  of  the  functionality  of  scrolling,  but  allows  for 
movement  in  two,  instead  of  one,  dimensions.  The  panning  is  done  by  asking  the  user 
to  input  two  points,  the  first  point  is  the  displayed  at  the  second  position,  thus  translating 
the  data  in  one  or  two  dimensions.  A  zooming  function  was  implemented,  which  allows 
for  either  a  scaled  zoom,  based  on  an  input  zooming  factor.  This  factor  is  defined  to  be 
always  positive  with  factors  less  than  one  being  zoom  out  and  those  greater  than  one 
being  zoom  in.  The  zooming  function  also  allows  a  user  to  define  a  square  area,  by  a 
center  and  rubber-banding  square  box,  which  will  display  all  data  contained  within  the 
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box. 


Other  display  functions  include,  redraw,  dump,  grid,  and  locate.  The  redraw  func- 
tion does  just  that,  it  redraws  the  map.  The  dump  function  does  a  dump  of  the  map  win- 
dow, in  xwd  style,  so  that  that  map  can  be  dumped  to  the  laser  printer  (using  Iwxpr).  The 
grid  function  places  a  constant  size  grid  over  the  data,  for  reference.  The  locate  func- 
tion is  an  unimplemented  function,  which  will  allow  for  database  queries,  to  allow  for 
direct  movement  to  some  section  of  the  map. 

Newly  planned  functions  include,  a  display  of  the  current  map  scale,  and  a  Univer- 
sal Transverse  Mercator  (UTM)  coordinate  display,  which  will  indicate  the  UTM  coordi- 
nates of  the  mouse  position. 

Currently,  stubs  (null  menu  items)  have  been  placed  which  provide  the  complete 
user  interface  for  the  unimplemented  portions  of  the  project.  Although  these  are  not  part 
of  the  work  planned  for  this  course,  they  do  provide  some  insight  into  the  final  func- 
tionality of  the  system.  Also  implemented  is  a  dynamically  displayed  menu  hierarchy, 
which  will  be  used  for  the  maintenance  management  portion  of  the  project. 

The  entire  state  of  Indiana  is  available  in  1:100,000-scale  digital  planimetric  data 
corresponding  to  the  USGS  1 :100,000-scale  map  quadrangles.  These  digital  line  graphs 
include  data  in  two  categories,  hydrograhic  and  transportation.  The  data  is  currently  sold 
only  in  30-  by  30-minute  blocks,  making  it  necessary  to  purchase  two  files  to  cover  one 
30-  by  60-minute  quadrangle  with  the  hydrography  and  transportation  layers  sold 
separately.  The  state  is  covered  by  approximately  33  1 :100,000-scale  map  quadrangles 
or  approximately  56  sets  of  data. 

As  of  January  1,  1988  there  were  only  19  available  or  soon  to  be  available  digital 
line  graphs  from  1 :24,000-scale  maps  out  of  a  total  of  approximately  700  to  cover  the 
entire  state.  There  is  no  time  table  for  the  digitization  of  data  at  this  resolution,  it  is  done 
on  the  basis  of  demand  and  project  coordination  with  the  U.S.  Geological  Survey.  For 
example,  the  state  of  Connecticut  is  currently  digitized  at  a  resolution  of  1 :24,000-scale 
as  a  result  of  a  state  wide  geographic  information  system  project  that  was  undertaken 
for  the  mutual  benefit  of  the  State  and  Federal  government.  Therefore  unless  an  ade- 
quate and  desirable  reason  arises,  for  the  most  part  the  state  of  Indiana  will  remain 
undigitized  at  this  resolution  indefinitely. 

5.2  Structure  and  Function  of  SNORODES 

The  preliminary  analysis  of  the  problem  has  yielded  the  proposed  decision  support  sys- 
tem presented  in  Figure  6  to  aid  in  the  solution  of  the  problem.  The  database  for  the 
system  is  to  be  some  variation  of  a  geographic  information  system  which  is  an 
enhanced  spatial  database  with  various  analysis  tools  attached.  The  "route  designer"  is 
a  mathematical  model  which  will  take  the  network  data  as  input  and  output  optimal  sets 
of  routes  to  be  analyzed.  The  routes  will  be  passed  to  a  routine  that  will  transform  the 
route  parameters  such  that  they  can  be  displayed  and  manipulated  through  an  interac- 
tive routine  controlled  by  the  user.  By  using  this  interactive  interface,  the  user  will  be 
able  to  test  alternative  routes  by  making  frequent  and  rapid  changes  to  the  configuration 
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Figure  6:  Route  Design  System  Framework 


suggested  by  the  model.  The  resulting  route  configuration  can  be  evaluated  based  on 
performance  measures  and,  if  necessary,  passed  to  the  route  design  module  for  further 
analysis  and  modification.  The  proposed  system  will  reach  the  best  possible  solution  in 
a  mathematical,  network  theory  or  quantitative  sense  while  at  the  same  time  involving 
the  user  and  his/her  special  knowledge  with  regard  to  the  local  area  and  constraints  via 
its  interactive  and  iterative  solution  procedure.  The  remainder  of  this  section  discusses 
the  possible  application  of  fuzzy  set  theory  for  two  components  of  the  system,  the  math 
model  and  the  knowledge-based  decision  support  module. 

The  mathematical  model  is  responsible  for  generating  sets  of  optimal  routes  given 
the  network  and  problem  constraints.  The  network  may  be  viewed  as  a  collection  of  arcs 
(roads)  and  nodes  (intersections  or  turnarounds)  with  their  respective  attributes  and 
connectivity  included.  Some  of  these  attributes  are  road  width,  directional  sense,  and 
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classification  or  priority  rating.  These  classifications  or  priority  ratings  have  been  discre- 
tized  into  three  crisp  sets  based  on  the  road  type  and  traffic  volume  with  class  one  roads 
having  the  highest  service  priority;  continuous  service  during  a  storm.  One  objective  of 
this  research  is  to  examine  the  highway  department's  current  policy  with  regard  to  the 
entire  snow  removal  operation  and  make  recommendations  for  possible  revisions  that 
will  improve  efficiency  without  sacrificing  a  given  minimal  level  of  service.  This  road 
priority  scheme  may  be  one  area  that  could  benefit  from  a  fuzzy  approach. 

The  highway  department  claims  that  there  are  many  exceptions  to  the  current 
classification  scheme  based  on  based  on  local  importance  of  a  particular  road  due  to 
such  factors  as  emergency  service  facilities  (eg.  hospitals,  fire  stations,  etc.)  located  on 
a  lower  class  road.  Conditions  such  as  these  cause  the  local  decision  makers  to 
request  a  change  of  classification.  The  author  proposes  the  possibility  of  making  road- 
way importance  a  fuzzy  variable  based  on  the  policy  specifications  and  special  local 
knowledge.  This  would  relax  the  limiting  three  class  scheme  and  create  a  more  realistic 
parameter  for  a  roadway's  importance.  This  in  turn  would  insert  a  qualitative  or  human 
judgemental  element  into  a  very  quantitatively  assuming  model. 

Furthermore,  the  mathematical  model  is  to  be  formulated  as  a  variant  of  an  arc  or 
node  covering  linear  program  with  multiple  objectives;  minimizing  "deadhead"  miles  and 
cost  while  maximizing  the  level  of  service.  The  arc  or  node  covering  formulations  are 
known  as  the  "Chinese  Postman  problem"  and  the  "Traveling  Salesman  problem" 
respectively.  Both  of  these  algorithms  have  been  thoroughly  researched  and  covered  in 
the  literature,  but  the  snow  removal  problem  presents  some  special  problems  for  them. 
These  problems,  multiple  vehicles  and  passes  on  an  arc,  and  the  dynamic  and  indivi- 
dual characteristics  of  each  storm,  can  be  considered  special  cases  of  the  previously 
mentioned  algorithms  that  induce  additional  constraints  and  complicate  the  network  for- 
mulation. This  could  lead  to  an  overconstrained  or  unsolvable  problem.  At  this  point  sim- 
plifying assumptions  are  sometimes  made  so  as  to  avoid  trying  to  quantify  and  formulate 
constraints  for  qualitative  and  imprecise  problem  parameters  such  as:  truck  speed, 
storm  severity,  arc  type  and  time  to  clear  it.  The  theory  of  fuzzy  sets  applied  to  network 
theory  and  linear  programming  could  help  deal  with  these  imprecise  and  qualitative 
modeling  constraints. 

The  knowledge-based  decision  support  or  analysis  module  in  the  system  is  to  be 
designed  to  help  judge  and  design  the  routes  with  the  user.  Recently  there  has  been  a 
tremendous  amount  of  research,  literature,  and  hype  surrounding  the  development  and 
application  of  knowledge-based  or  expert  systems  and  their  potential  role  in  engineering 
decision  making.  This  role  is  in  the  area  of  how  these  systems  represent  uncertainty 
and  infer  solutions  from  the  knowledge  they  contain  and  is  input.  This  part  of  the  system 
will  receive  a  set  of  routes  and  performance  indicators  that  the  decision  support  module 
must  analyze  and  judge  with  the  help  of  the  user  and  his/her  opinion.  One  point  that 
should  be  made  is  the  importance  of  analyzing  the  type  of  knowledge  and  logical  infer- 
ence that  takes  place  in  any  particular  problem  when  using  an  expert  system  technol- 
ogy. There  are  a  wide  variety  of  tools  and  methodologies  available  for  development 
work  in  this  area  and  the  more  cerebral  aspects  of  inference  and  uncertainty  propaga- 
tion can  easily  be  taken  for  granted  in  a  higher  level  tool.  This  could  be  dangerous 
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because  some  problems  may  not  be  well  suited  for  a  particular  tool.  That  is,  one  may 
be  able  to  force  his/her  problem  to  fit  into  the  scheme  of  the  tool  and  get  solutions,  but 
those  solutions  may  not  be  completely  valid  because  of  the  previously  mentioned  uncer- 
tainty and  inference  logic. 
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6.  DIRECTIONS  FOR  FUTURE  RESEARCH 

This  research  has  demonstrated  the  feasibility  of  constructing  a  route  design  and 
analysis  system  for  highway  maintenance  and  service  activities  such  as  wintertime 
snow  and  ice  control.  The  following  specific  tasks  would  be  needed  to  implement  such 
a  system  for  the  State  of  Indiana: 

1.  Establishment  of  a  compter  platform  sufficient  to  support  the  interactive  graphics 
and  numerical  computation  necessary  to  perform  automated  mapping  functions. 

2.  Acquisition  of  statewide  data  from  the  USGS  which  are  presently  available  in  digi- 
tal form. 

3.  Conversion  of  USGS  transportation  data  to  state  resolution  using  the  methods  dis- 
cussed in  Chapter  4. 

4.  Further  development  of  the  SNORODES  user  interface  with  new  provisions  for 
network  data  editing  and  color  enhancement  of  route  information  including  the 
capability  of  producing  hard-copy  color  maps. 

5.  Implementation  of  the  SNORODES  analysis  system  as  discussed  in  Chapter  3  of 
this  report  and  described  further  in  Chapter  5  as  necessary. 

6.  Training  of  IDOH  personnel  in  the  use  of  the  system. 

7.  Exposure  of  the  final  system  to  IDOH  engineers  in  an  attempt  to  identify  other 
route  oriented  activities  that  might  take  advantage  of  this  unique  and  powerful 
technology. 
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APPENDIX  A  -  Code  for  Optimization  Model 
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FINAL  REPORT:  Prototype  Route  Design  System 


APPENDIX  B  -  Sample  SNORODES  Session 


Project  Number  C-36-67AA  File  Number  9-1 1  -27 
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State 

Intersection                           Segment                          Route 

Region                           Project                           Quit 

Map 

Zoom 

SNOw   ROute    Design    and   Evaluation 

System 

Developed  for  the  Indiana  Department  of  Highways 

N-— -"" 

1 

Research  Team  : 

" 

District 

Jeff  R.  Wright  -  Principal  Investigator 

Edward  Haslam  -  Research  Assistant 

Paul  Kurmas  -  Research  Assistant/Database 

■ 

Pan 

Kurt  Buehler  -  Graphics/User  Interface 

■I 

Salah  Benabdallah  -  Research  Assistant 

II 

■ 

Subdistrict 

■l 

1 

Grid 

County 

Redraw 

City 

Dump 

Scale 

Measure 

The  SNOw  ROute  Design  and  Evaluation  System  (SNORODES)  is  a  highly  interactive  inter- 
face to  an  extensive  roadway  information  management  system.  The  SNORODES  prototype  is 
presently  being  used  to  study  the  design  of  snow  and  ice  control  routes  for  the  Indiana  Depart- 
ment of  Highways  (IDOH).  The  SNORODES  display  consists  of  a  large  information  display 
screen  (center  portion  of  the  screen)  and  three  separate  menu  strips  along  the  top  and  sides  of 
the  display  window.  The  menu  strip  along  the  right  controls  map  manipulation.  The  menu  strip 
along  the  tip  controls  feature  location.  And  the  strip  along  the  left  allows  information  sum- 
Q?ar'es  at  various  levels.  By  pointing  at  a  particular  data  cell  (shaded  square  on  the  Indiana 
Outline)  the  user  may  request  the  desired  map  reference 
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In  this  example,  the  mouse  cursor  — X —  is  placed  in  the  center  of  the  4  data  cells  and  a  button 
on  the  mouse  is  pressed.  This  results  in  the  display  of  the  corresponding  map(s)  in  the  display 
window  as  shown  below  (the  region  being  used  for  the  test  case  includes  the  Fowler  Sub-dis- 
trict of  the  Crawfordsville  District  Office,  IDOH).  The  map  being  displayed  may  be  changed  in 
several  ways  using  the  menu  strip  along  the  right  hand  side  of  the  screen.  Such  things  as 
zooming  (changing  the  field  of  view),  panning  (changing  the  map  position),  and  various  scaling 
and  measurement  features  are  available  as  well  as  options  for  printing  map  displays. 


Suppose,  for  example,  we  are  interested  in  looking  at  a  smaller  region  just  to  the  West  of  West 
Lafayette  along  the  Wabash  River.  To  select  the  zoom  option  from  the  menu  strip,  we  would 
position  the  cursor  near  the  "zoom"  menu  label  using  the  mouse.  When  the  cursor  is  correctly 
positioned,  the  menu  item  is  shaded  as  shown  in  the  following  display. 
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By  pushing  or  "clicking"  a  mouse  button  with  the  cursor  in  this  position,  a  second  menu — a 
zoom  menu —  emerges  and  a  new  cursor — * —  appears  to  emphasize  a  change  in  user  mode. 
As  with  most  SNORODES  routines,  several  options  exist  for  conducting  the  zoom  operation. 
In  this  case  we  may  select  a  "scale"  option  allowing  us  to  change  the  power-of-magnification 
on  the  display  window,  or  a  "window"  zoom  operation.  We  demonstrate  the  window  zoom 
option  by  positioning  the  cursor  in  the  "Window"  option  cell  and  clicking  a  mouse  button. 
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The  window  zoom  procedure  assumes  that  the  user  is  interested  in  zooming  in  on  a  specific 
feature  or  region.  The  user  identifies  that  feature  as  closely  as  possible  on  the  current  map 
display  and  positions  the  cursor  at  that  location.  That  point  will  become  the  center  of  the 
zoomed  display  when  the  user  clicks  a  mouse  button.  In  this  example,  the  cursor  position  is 
near  the  center  of  the  display  window. 

At  present,  there  are  no  explicit  instructions  for  the  user  when  using  this  zoom  procedure.  Future  plans  call  for  the  inclusion 
of  a  small  instruction  window  across  the  bottom  of  the  display  window  that  will  provide  access  to  more  extensive  "help"  rou- 
tines. 
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Next,  the  user  must  decide  how  big  the  resulting  zoomed  window  display  will  be.  As  the  user 
moves  the  cursor  away  from  the  center  point,  an  elastic  window  grows  with  proportions  equal  to 
those  of  the  display  window.  The  shaded  square  near  the  center  of  the  display  window  in  the 
figure  below  represents  this  sizing  window.  When  the  mouse  button  is  pressed  a  second  time, 
the  size  of  the  resulting  zoomed  window  is  established;  the  map  area  in  the  sizing  window  will 
be  enlarged  to  fill  the  display  window  as  shown  in  the  following  display. 
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Another  map  manipulation  capability  is  the  "pan"  procedure  that  allows  the  displayed  map  to  be 
moved  in  the  display  window.  The  magnification  of  the  map  image  remains  unchanged  during 
this  procedure.  At  present,  only  one  pan  option  exists  which  is  invoked  in  a  manner  similar  to 
the  zoom  option.  First,  the  user  moves  the  cursor  to  the  general  vicinity  of  the  pan  menu  label 
and  invokes  the  sub-menu.  Once  again,  the  label  is  shaded  to  confirm  the  selection  and  the 
cursor  is  changed  for  sub-menu  selection. 
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A  pan  is  conducted  in  four  steps.  First,  the  user  is  asked  to  select  a  point  anywhere  on  the 
display  map.  This  point  will  subsequently  be  moved  to  another  location  on  the  display  window 
achieving  a  shifting  of  the  present  map  image  without  changing  magnification.  After  confirming 
the  instruction  by  clicking  the  mouse  in  the  "ok"  button,  the  user  moves  a  target  cursor  to  the 
desired  location  on  the  map. 

Note  that  for  purposes  of  this  example,  a  different  level  of  magnification  is  used  to  bring  out  important  map  detail. 
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In  this  example,  the  user  has  chosen  a  point  very  near  the  right  edge  of  the  display  window;  a 
point  in  the  approximate  center  of  the  Wabash  River.  When  the  user  clicks  the  mouse  at  this 
point,  a  request  for  a  second  point  is  made. 


Features 
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This  second  point  in  the  display  window  will  become  the  new  position  of  the  first  point  selected. 
That  is,  the  first  point  selected  will  be  dragged  to  the  window  location  of  the  second  point  and 
with  it,  the  map  will  be  moved  achieving  the  pan  manipulation.  Once  again,  the  user  is  asked 
to  confirm  the  instruction. 
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For  our  example,  the  second  point  selected  by  the  user  is  approximately  half  way  between  the 
center  of  the  display  and  the  left  edge,  about  40%  up  from  the  bottom  of  the  display.  When  the 
user  clicks  the  mouse  at  this  point... 
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...the  screen  display  is  redrawn  with  the  map  shifted  to  the  left  in  the  window.  The  first  point 
selected  now  occupies  the  location  of  the  second  point  selected.  Using  an  appropriate  combi- 
nation of  the  pan  and  zoom  options,  the  user  may  display  any  portion  of  the  highway  network 
that  is  desired  and  at  any  level  of  detail.  Using  other  map  manipulation  options,  any  map 
display  may  be  scaled,  measured  (point-to-point)  or  printed. 
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The  feature  location  menu  located  across  the  top  of  the  display  window  may  be  used  at  any 
time  to  locate  portions  of  the  network  of  interest  according  to  type.  For  example,  a  user  might 
be  interested  in  locating  a  particular  roadway  segment  or  route,  or  possibly  a  specific  project. 
All  features  may  be  linked  to  sophisticated  database  structures  for  detailed  analysis.  As  an 
example,  suppose  we  are  interested  in  information  about  a  particular  intersection  on  the  net- 
work. We  may  use  the  mouse  to  locate  the  "Intersection"  menu  label  and  select  the  "Display" 
option  from  the  sub-menu. 


Subdistrict 


County 


City 


Suppose  we  are  interested  in  the  intersection  of  1-65  and  SR-25,  which  is  displayed  near  the 
center  of  the  map.  After  choosing  the  display  option,  we  would  click  the  mouse  in  the  vicinity  of 
that  intersection  resulting  in  the  display  of  the  first  of  possibly  several  design  drawings  of  that 
intersection. 
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The  drawing  shown  in  this  example  is  a  very  crude  representation  of  an  actual  design  blueprint. 
But  it  serves  to  demonstrate  that  all  important  features  of  the  intersection  may  be  represented 
visually  on  the  screen  in  much  the  same  fashion  as  they  exist  in  paper  form.  Though  there  is 
only  one  such  drawing  for  this  example,  multiple  drawings  could  be  displayed  as  controlled  by 
a  menu  that  may  be  "raised"  by  the  click  of  a  mouse  button.  With  program  modifications,  each 
drawing  could  be  modified  in  a  design  change  operation  using  a  modern  computer  aided 
design  (CAD)  program. 
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Next,  the  database  management  function  of  the  system  is  demonstrated.  Suppose  we  are 
interested  in  conducting  an  inventory  of  items  at  that  intersection  or  in  locating  specific  charac- 
teristics or  a  history  of  a  particular  item.  By  selecting  the  "Inventory"  option  from  the  Intersec- 
tion sub-menu,  the  main  display  window  changes  to  a  database  menu. 
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Several  options  are  also  available  within  the  database  system.  We  we  will  invoke  a  query 
option — menu  item  number  3 —  so  that  we  may  investigate  the  materials  inventory  for  the  inter- 
section. 


[malnmenu]                                                 UNIFY   Release   3.2 
UNIFY   Main   Menu 

24   MAY    1988   - 

-   12:42 

State 

1.  Design  and  Create   a  Neu  Data   Base 

2.  Create   or   Modify    Screen   Forms 

Zoom 

j.  gmmyuMJjyMEBjEB 

District 

A.    Edit   SQL  or  RPT  Command  Files 

5.  Add.    Modify    or   Delete   Menus 

6.  Data   Base   Design  Utilities 

7.  System  Administration 

Pan 

Subdlstrlct 

B.    Data   Entry    Screens 

Grid 

County 

Redraw 

City 

I 

Damp 
Scale 

Measure 

911    UiCJII    IB 

nisias 
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Using  the  standard  query  language  (SQL)  available  on  all  major  database  management  sys- 
tems, we  can  first  display  the  records  and  field  specifications  making  up  the  schema  of  this 
system.  In  this  case,  four  different  database  record  types  have  been  specified:  tcard  (time 
card  information),  invent  (location  inventory),  pipe,  and  rail. 


Subdisttlct 


County 


City 


[sqll 


UNIFY  Release  3.2 
SQL  -  Query/DHL  Language 
UNIFY  SQL  —  VERSION  3.2 
Copyright  Unify  Corporation  1983.1984.1985 


sql>  records 

tcard    Invent   pipe     rail 

sql>  fields  tcard 

NAME 

NUMBER 

DATE 

ROUTES 

MANHOURS 

MANEQUIP 

PLOUHOURS 

PLOUPASSES 

SALTPASSES 

ABRASPASSES 

CALCPA5SES 

SALT.ABR 

sql>  fields  pipe 

NAME 

STRUCTURE_NO 

LENGTH 

DIAMETER 

sql>  fields  Invent 

NAME 

IDNUMBER 
DESCRIPTION 
sql>  fields  rail 
NAME 

STATION 
IDNUMBER 
SIDE 

LINEARFEET 
sql>  | 


24  MAY  1988  -  12:53 


NUMERIC 

5 

STRING 

8 

STRING 

25 

FLOAT 

32 

FLOAT 

32 

NUMERIC 

3 

NUMERIC 

2 

NUMERIC 

2 

NUMERIC 

2 

NUMERIC 

2 

NUMERIC 

2 

TYPE 

LENGTH 

STRING 

4 

NUMERIC 

4 

NUMERIC 

4 

TYPE 

LENGTH 

STRING 

4 

STRING 

60 

TYPE 

LENGTH 

STRING 

25 

STRING 

4 

STRING 

20 

NUMERIC 

3 

Dump 
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A  series  of  query  calls  to  the  database  will  demonstrate  its  convenience  and  flexibility.  First, 
we  would  like  a  listing  of  all  major  inventory  items  at  that  location.  The  request  select  * 
from  invent  says  "from  the  database  'invnet',  select  all  items  (*)  and  display  the  results  of 
this  operation."  The  result  is  a  listing,  by  item  ID  number  and  description. 


■■1 

sql>  select  » 

H 

sql>  from  Invent/ 

State 

recognized  query  I 
IDNUMBER 1  DESCRIPTION 

Zoom 

B       110"  reinforced  concrete  pavement 

A       19"  continuously  reinforced  concrete  pavement 

6       11"  preformed  expansion  Joint  ui/load  transfer 

9        11"  preformed  Joint  filler 

District 

32       1  terminal  Joint  for  crc  pavement 

34  Ibltumlnous  shoulder  3" 

35  Ibltumlnous  shoulder  5" 

36  Itype  "P"  compacted  aggregate  base 

37  1  guard  rail 

44  1  special  concrete  curb 

45  13"  bituminous  shoulder  on  7"  type  "P"  compacted  aggregate  base 
91       1  Inlet  and  pipe 

Pan 

Subdistrlct 

93  Iplpe 

94  Iplpe 

95  1  Inlet  and  pipe 

96  Unlet  and  pipe 

97  Iplpe 

100  1  inlet  and  pipe 

101  Iplpe 

102  Iplpe 

Grid 

County 

105      Unlet  and  pipe                          T 
IDNUMBERIDESCRIPTION 

Redraw 

109      1  inlet  and  pipe 

111      1  inlet  and  pipe 

112      1  Inlet  and  pipe 

113      1  inlet  and  pipe 

114      Iplpe 

City 

115      1  inlet  and  pipe 

122  Iplpe 

123  Ipipe 
121      Iplpe 

127  Iplpe 

128  1  inlet  and  pipe 

130  Iplpe 

131  1  Inlet  and  pipe 

Dump 

132      Iplpe 

Scale 

133      1  Inlet  and  pipe 

134      1  Inlet  and  pipe 

151      Unlet  and  pipe 

152      1  inlet  and  pipe 

169      1  Inlet  and  pipe 

170      1  inlet  and  pipe 

171      Unlet  and  pipe 

IDNUMBERIDESCRIPTION 

Measure 

172      1  Inlet  and  pipe 

sol>  I 
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A  similar  query  can  be  made  to  get  a  complete  listing  of  the  contents  of  the  pipe  record. 


Csql]                         UNIFY  Release  3.2           24  MAY  1988  -  12:55 

SQL  -  Query/DML  Language 

UNIFY  SQL  —  VERSION  3.2 

State 

Copyright  Unify  Corporation  1983.1984.1985 

sql>  select  « 
sql>  from  pipe/ 
recognized  query  1 

STRUCTURE.NO 1  LENGTH  1  DIAMETER 

Zoom 

District 

91           1     941       12 

93  1    1221       24 

94  1     941       30 

95  1     551       12 

96  1    1221       12 

97  1    8021      66 
100         1    1501       12 

Pan 

Subdistrict 

101  1     94  1        6 

102  1     941        6 

105          1    124  1       12                                                      v 
109          t    1301       12                                                      ± 

Grid 

111          1     781       12 

112         1    1101       12 

113         1    1121       12 

114         1     821       12 

115         1     821       12 

County 

122  1     961       6 

123  1     961       6 
121         1    1581      36 

127  1    3601      36 

128  1    1601       12 

Redraw 

City 

STRUCTURE_NO 1  LENGTH  1  DIAMETER 

Dump 

130          1    7661        6 

131         1    2381       12 

132          1    4681       42 

133         1    1611       12 

151          1    1041       12 

152         1     801       12 

169         1     801       12 

170         1     951       12 

171         1     591       12 

Scale 

172         1    1051       12 

sql>  | 

Measure 
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...and  from  the  rail  database  record.  But  much  more  complicated  (and  presumably  useful) 
database  queries  can  also  be  made.  For  example,  the  query  select  *  from  invent 
where  idnumber  =  '  97'  will  result  in  a  listing  of  only  that  item  from  the  inventory  record 
having  IDNUMBER  of  97.  Combined  requests  can  be  made  between  attributes  of  different 
database  records  as  well. 


■a 

Csql]                         UNIFY  Release  3.2 

24  MAY  1988  - 

•  13:00 

SQL  -  Query/DML  Language 

UNIFY  SQL  —  VERSION  3.2 

State 

Copyright  Unify  Corporation  1983. 1984. 1985 

sql>  select  « 
sql>  from  rail/ 
recognized  query  1 

Zoom 

District 

STATION                   IIDNUMBERISIDE 

LINEARFEET 

Fan 

694+63-694+91.5          137      Isb  outside 

285 

694+80-695+09            137      Isb  inside 

285 

696+83-698+20             137       Isb  outside 

136 

697+00-700+36             137       Isb  Inside 

336 

691+82-695+28            137      1  nb  inside 

336 

694+11-695+47             137       1 nb  outside 

136 

696+18-696+46             137       Inb  inside 

28 

Subdlsulct 

697+35-697+63             137       Inb  outside 

sql> 

sql> 

28 

I 

Grid 

sql>  select  » 

sql>  from  Invent 

sql>  where  IDNUMBER  =  '97   */ 

recognized  query  1 

I DNUMBER 1 DESCR I PT I ON 

Co  only 

Redraw 

97       Ipipe 

sql> 

sql> 

sql>  select  « 

sql>  from  pipe 

sql>  where  STRUCTURE_N0  =  '97   */ 

recognized  query  1 

City 

STRUCTURE_N0 1  LENGTH  1  DIAMETER 

97           1    8021       66 
sql>  | 

Dump 
Scale 
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The  SNORODES  system  is  modeled  after  the  specifications  for  the  IDOH  Maintenance  Mange- 
ment  System  as  much  as  possible.  For  example,  the  "Projects"  item  on  the  features  menu  has 
a  sub-menu  consisting  of  "Work  Activities"  and  "Resource  Costs."  The  selection  of  the  Work 
Activities  option  results  in  a  second  sub-menu  as  shown  on  the  following  display. 
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Each  of  the  items  in  the  Work  Activities  sub-menu —  Average  Daily  Production,  Standard  Crew 
Size,  Equipment  Needs,  and  Materials  Needed — pertain  to  some  aspect  of  a  specific  project. 
This  information  might  be  useful  in  the  preparation  of  weekly,  monthly,  and  final  project  reports 
as  well  as  providing  current  information  about  all  aspects  of  a  given  project  at  any  point  in  time. 
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The  "Analysis"  menu  items  located  along  the  left  side  of  the  display  window  allow  the  user  to 
generate  and  analyze  summary  information  at  different  levels  of  operation.  One  might  be 
interested  in  State-wide  information  such  as  total  expenditures  for  a  particular  activity  within  all 
districts.  Alternately,  we  might  be  interested  in  a  specific  item  of  information  within  some 
smaller  regional  unit.  As  an  example,  suppose  we  are  interested  in  the  total  work  level  on  a 
particular  route  within  the  Crawfordsville  Sub-district.  We  would  first  select  the  "District" 
analysis  level... 


..then  select  the  Crawfordsville  District... 
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Seymour 


...then  select  the  "Work  Activities"  menu  item.  This  selection 
will  return  us  to  the  database  query  window  where  we  can 
perform  different  analyses  on  the  information  contained  there. 
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Once  again,  we  may  formulate  rather  complex  requests  to  the  database  using  convenient  syn- 
tax, select  sum  (MANHOURS)  from  tcard  performs  a  simple  addition  of  total  manhours 
from  the  appropriate  entry  in  the  tcard  database.  To  be  more  specific  for  the  route  of  interest, 
the  query  select  sum  (MANHOURS)  from  tcard  where  ROUTES  =  '13-f-2*' 
reports  the  total  work  effort  on  those  routes  having  identifications 
starting    with   the    string    13-f-2. 
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County 


City 


unify 


Csql]  UNIFY  Release  3.2 

SOL  -  Query /Dml  Language 
UNIFY  SQL  —  VERSION  3.2 
Copyright  Unify  Corporation  1983. 1984. 19B5 

sql>  select  »um(MANHOURS> 
sql>  from  tcard 
sql>  / 
recognized  query  I 

sum (MANHOURS) 


24  MAY  1988  -  13:18 


8147.00000 
sql> 
sql> 

sql>  select  sum(HANHOURS) 
sql>  from  tcard 

sql>  where  ROUTES  =  *13-f-2-V 
recognized  query ! 

sum (MANHOURS) 


368.50000 


sql> 
sql> 
sql> 


Dump 
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Once  again,  we  may  formulate  rather  complex  requests  to  the  database  using  convenient  syn- 
tax, select  sum(MANHOURS)  from  tcard  performs  a  simple  addition  of  total  manhours 
from  the  appropriate  entry  in  the  tcard  database.  To  be  more  specific  for  the  route  of  interest, 
the  query  select  sum(MANHOURS)  from  tcard  where  ROUTES  =  '13-f-2*' 
reports  the  total  work  effort  on  those  routes  having  identifications 
starting   with   the    string    13-f-2. 


State 

Zoom 

Csql]                         UNIFY  Release  3.2 

SQL  -  Query/DML  Language 
UNIFY  SQL  --  VERSION  3.2 
Copyright  Unify  Corporation  19B3. 1964. 1965 

24  MAY  1988  - 

■  13:16 

sql>  select  sum ( MANHOURS ) 
sql>  from  tcard 
sql>  / 
recognized  query  1 

District 

sum (MANHOURS) 

Fan 

6147.00000 
sql> 
sql> 

sql>  select  sum(MANHOURS) 
sql>  from  tcard 
sql>  where  ROUTES  =  '13-f-2«V 

Subdlstrlet 

recognized  query  1 
sum(MANHOURS) 

I 

Grid 

368.50000 
sql> 
sql> 
sql>  | 

County 

Redraw 

City 

Dump 
Scale 
Measure 

64 


APPENDIX  C  -  Glossary 
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Glossary 

Attribute  codes.  A  pair  of  figures  to  describe  the  class  of  a  road 

Client  An  application  program 

Lagrangian  relaxation.  A  technique  of  optimization 

Protocal.  A  mechanism  to  connect  application  program  to  the  workstation 

Socket.  A  file  which  can  send  data  into  process  on  a  UNIX  system 

USGS.  United  States  Geological  Survey 

XML.  A  mechanism  to  generate  the  input  for  XMP 

XMP.  An  optimization  software 

Iwxpr.  A  command  to  print  the  screen  dump  file  from  a  laser  printer 

xwd.  A  command  in  X  window  to  dump  the  contents  of  a  certain  screen 


